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ABSTRACT 

The  goal  of  condition-based  maintenance  (CBM)  is 
to  optimize  operational  readiness  of  equipment  through 
predictive  and  proactive  maintenance.  This  capability 
requires  accurate  prediction  of  the  remaining  useful 
lifetime  of  each  component,  so  that  each  may  be  replaced 
shortly  before  it  is  likely  to  impair  mission  readiness.  By 
reducing  unnecessary  component  replacements  while 
still  providing  effective  maintenance,  effective  Condition 
Based  Maintenance  ensures  reliability  of  the  warfighter’s 
equipment  at  lessened  expense,  thus  enhancing  mission 
capability. 

The  practice  of  forming  predictions  of  component 
reliability  is  called  prognostics.  In  this  paper  we 
consider  the  application  of  prognostics  to  military 
vehicles  utilizing  data  bus  architecture,  particularly  in  the 
context  of  the  Advanced  Multiplex  Test  System  (AMTS). 
We  discuss  several  methods  of  designing  prognostics 
(including  incorporating  the  use  of  machine  learning)  as 
well  as  the  barriers  existing  in  this  domain  environment 
both  to  design  and  implementation  of  effective  predictive 
maintenance.  We  present  a  variety  of  suggestions  for  a 
gradual  approach  to  developing  prognostics  capabilities 
in  this  setting. 


1.  INTRODUCTION  TO  PROGNOSTICS 

The  intent  of  condition-based  maintenance  (CBM)  is 
to  optimize  operational  readiness  by  intelligent 
replacement  of  components  only  shortly  before  they 
would  become  operation  incapable.  For  this  concept  to 
be  implemented  in  an  economically  sustainable  way,  it 
must  be  possible  to  predict  with  reasonable  reliability  the 
time  to  failure  for  each  individual  component,  based  on 
its  actual  operating  environment,  monitored  health,  and 
usage  level.  The  study  and  practice  of  failure  prediction 
for  components  is  known  as  prognostics .  Note  how  this 
is  distinguished  from  diagnostics,  which  concerns  only 
the  analysis  of  the  current  condition  and  capability  of 
components,  and  of  the  causes  of  existing  failures. 


In  the  context  of  this  study  we  focus  on  field 
maintenance.  Maintainers  in  our  domain  setting  cannot 
attempt  to  repair  a  component  themselves,  only  decide 
whether  or  not  to  replace  it  (and  send  it  to  the  depot  for 
bench  service).  This  decision  to  retain  or  replace  is 
based  on  guidelines  known  as  replacement  rules.  This 
limitation  somewhat  simplifies  the  prognostics  issues. 

1.1.  Possible  indicators  of  useful  lifetime  remaining 

There  are  three  general  classes  of  data  that  may  be 
utilized  in  deriving  an  estimate  of  remaining  useful  life 
of  a  component. 

The  simplest  type  of  data  to  capture,  and 
historically,  that  first  used  for  prognostics  is  given  by: 

Elapsed  time.  This  is  sometimes  defined  as  the 
time  that  the  unit  has  been  in  active  use,  and  sometimes 
as  total  time  elapsed  (which  may  be  measured  either 
from  the  date  of  a  component’s  manufacture,  or  from  its 
last  bench  service). 

The  assumption  that  the  probability  of  failure  is  a 
simple  function  of  time  leads  to  easy  replacement  rules. 
However,  often  failure  probability  is  not  a  simple 
function  of  time.  In  a  landmark  study  of  aircraft 
components,  six  categories  of  age -reliability  curves  were 
observed.  Of  these  six,  only  three  reflected  failure 
patterns  that  might  benefit  from  imposing  a  limit  on 
operating  age;  and  these  three  types  were  observed  in 
only  11%  of  all  components  studied  (Nolan  and  Heap, 
1978). 

The  demonstrated  inadequacy  of  solely  time -based 
predictions  leads  to: 

Current  measured  condition.  Here,  replacement 
guidelines  are  based  on  measurable  or  observable  aspects 
of  the  component’s  current  condition.  Typically  this 
might  be  defined  as  deviation  of  one  or  more  health  or 
performance  metrics  from  certain  pre-defined  acceptable 
ranges  for  that  type  of  component. 
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This  concept  is  simple  and  the  principle  seems 
obvious.  However,  even  here,  there  are  pre-suppositions 
that  do  not  hold  for  all  types  of  components  and  types  of 
failures.  It  must  be  possible  to  detect  some  condition 
indicating  potential  future  failure,  and  there  must  some 
reasonable  consistency  in  the  period  between  this 
condition  manifestation  and  failure  of  the  item. 
Implementation  even  then  may  be  difficult.  New  sensors 
may  be  required  for  monitoring  conditions  continuously. 
In  some  cases,  the  use  of  sensors  or  monitoring 
equipment  may  be  incompatible  with  normal  operating 
conditions.  If  maintenance  inspections  require  a  special 
working  state,  certain  problems  may  not  manifest  in  this 
state.  The  root  assumption  itself,  that  future  behavior 
may  be  inferred  from  current  performance,  is  not  true  in 
all  cases. 

Trends  (changing  behavior  patterns).  This 
approach  involves  detecting  a  pattern  of  increasing 
deviation  over  time  of  one  or  more  metrics  from 
recorded  historical  ranges  for  that  particular  component, 
or  for  that  that  type  of  component.  A  sudden  shift  in  the 
rate  of  change  is  a  likely  indicator  of  increased  loss  of 
reliability. 

As  this  approach  combines  the  two  above,  it  is  the 
most  complex  to  design  and  implement.  Again,  it  is 
necessary  to  determine  a  characteristic  that  can  be 
tracked  and  for  which  some  change  in  behavior  is 
reasonably  correlated  with  eventual  failure,  although  this 
correlation  need  not  be  so  tightly  time -based  as  in  the 
second  approach. 

1.2.  Determinations  necessary  for  the  formation  of 
prognostics  replacement  rules 

Note  that  any  attempt  to  design  meaningful 
replacement  strategies  requires  deep  and  substantial 
knowledge  of  component  performance.  A  sample  of  the 
types  of  questions  which  need  to  be  addressed: 

•  What  class  of  function  best  approximates  the  time- 
or  condition-based  expectation  of  failure?  How  can 
one  derive  parameters  for  this  function? 

•  Which  specific  measurements  or  phenomena  are 
most  associated  with  decaying  performance?  How 
can  one  determine  acceptable  ranges? 

•  Precisely  which  physical  measures  are  important  to 
track  over  time?  What  constitutes  performance 
variation  which  is  not  merely  unusual,  but  unsafe? 

•  Do  performance  parameters  vary  based  on  operating 
environment? 

In  the  setting  of  this  study,  a  system  component  that 
has  been  removed  from  a  vehicle  in  order  to  receive 


bench  service  may  afterwards  be  installed  in  another 
vehicle  elsewhere. 

•  Is  it  possible  for  a  single  reliability  model  to 
function  effectively  regardless  of  usage,  or  do 
environmental  factors  require  consideration  and 
adjustment? 

•  If  a  component  has  been  previously  used  in  a 
different  system,  how  comparable  is  the  old  usage  to 
the  new?  Should  this  be  taken  into  account  when 
formulating  a  prediction,  and  if  so,  how? 

1.3.  Some  general  strategies  for  determining  and 
assessing  prognostics  factors 

Data  collection  and  analysis.  Such  a  process  often 
begins  with  lab  data  gathered  under  controlled 
circumstances,  but  ultimately  requires  field  data  for 
validation.  Arrays  of  sensors  and  diagnostic  equipment 
may  be  employed  to  gather  exhaustive  performance  data. 
Gathered  data,  whether  from  the  lab  or  field,  is  analyzed 
for  specific  indicators  and  patterns  of  performance 
degradation. 

Expert  systems.  In  cases  where  substantial  direct 
data  collection  is  impractical,  it  may  be  necessary  to 
consult  human  experts  with  substantial  experience 
observing  and  servicing  the  system.  From  their 
recommendations  some  “consensus  advice”  is  derived. 
An  expert  system  is  a  program  that  evaluates  data  and 
makes  decisions  based  on  these  human 
recommendations. 

Machine  learning.  Given  some  ability  to  ability  to 
assess  the  consequences  of  a  decision,  machine  learning 
can  be  utilized.  This  type  of  program  makes 
recommendations  based  on  every  previous  decision 
made  and  outcome  recorded.  Its  behavior  adjusts 
automatically;  over  time,  its  recommendations  should 
become  more  accurate.  Although  such  systems  can 
eventually  overcome  incorrect  initial  models,  they  do 
require  some  amount  of  initial  data  in  order  to  be  able  to 
offer  non-trivial  advice. 

It  is  possible  to  create  a  system  synthesizing 
elements  from  multiple  design  approaches  as  well. 

There  are  some  very  accessible  texts  describing 
existing  practices  in  predictive  and  preventative 
maintenance.  In  addition  to  Nowlan  and  Heap,  1978, 
another  good  general  source  is  Leemis,  1995.  So  far  as 
the  authors  are  aware,  the  idea  of  applying  artificial 
intelligence  techniques  to  predictive  maintenance  is  quite 
new. 
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1.4.  Pragmatic  limitations  on  determining  and 

implementing  replacement  rules 

Clearly,  each  of  the  above  strategies  may  involve  a 
certain  amount  of  time,  expense,  and  specialized 
resources,  or  may  be  infeasible  in  a  specific  domain  for 
some  reason.  Obtaining  trial  data  or  expert  advice  may 
both  be  very  difficult  in  some  domains. 

Even  if  replacement  rules  are  somehow  formulated, 
effective  implementation  requires  careful  record-keeping 
and  the  willing  cooperation  of  maintainers. 

Finally  but  importantly,  in  any  given  application  it  is 
difficult  to  estimate  whether  the  cost  of  necessary 
equipment,  software,  and  personnel  hours  to  design  and 
implement  a  maintenance  plan  incorporating  prognostics 
may  not,  in  practice,  exceed  the  expected  savings  in 
unnecessary  component  replacement.  Most  of  the  cost  is 
up-front,  the  savings  to  be  realized  in  the  future. 
However,  historically,  predictive  maintenance  plans  have 
often  paid  for  themselves  many  times  over.  For  a 
number  of  striking  case  studies,  see  Kececioglu,  1995, 
pp.  8-17. 


2.  BUS-ARCHITECTURE  VEHICLES: 

CONDITIONS  AND  POTENTIALS 

The  computer  systems  of  certain  military  vehicles 
consist  of  separate  digital  components  ( line  replaceable 
units,  or  LRUs)  linked  via  a  common  data  bus.  The 
Army  Communications  and  Electronics  Command 
(CECOM)  has  developed  a  portable  maintenance  device 
which  uses  the  bus  mechanism  to  inspect  all  of  these 
components,  and  to  isolate  any  failures,  in  a  single 
session.  Information  is  presented  to  the  user  in  a 
comprehensible  way,  obviating  the  need  to  refer  to 
manuals.  This  device  is  the  Advanced  Multiplex  Test 
System  (AMTS). 

AMTS  is  an  excellent  diagnostics  tool.  It  is 
CECOM’s  intention  to  supplement  its  current 
capabilities  by  incorporating  prognostic  information  and 
removal  recommendations. 

2.1.  Prevailing  conditions  of  the  domain  setting  and 

avenues  for  reliability  model  development 

Earlier  we  listed  three  general  approaches  to 
designing  prognostication  rules:  data  collection  and 
analysis;  expert  systems;  and  machine  learning.  We  also 
listed  three  general  classes  of  data  that  may  be  utilized 
by  replacement  rules:  elapsed  time;  current  condition 
measurements;  and  trends.  We  mentioned  some  caveats, 
including  variable  usage  conditions. 


When  we  began  this  study,  we  therefore  attempted 
to  analyze  the  existing  domain  conditions  affecting  the 
various  approaches  to  developing  and  implementing 
suitable  replacement  rules  for  the  Line  Replaceable  Units 
(LRUs)  on  the  data  bus. 

Some  of  the  following  information  was  obtained 
from  discussions  with  CECOM  personnel  associated 
with  the  AMTS  project.  We  also  interviewed  Army 
vehicle  maintainers  at  the  Johnstown  PA  aviation  facility 
to  gain  further  knowledge  of  domain  specifics.  Due  to 
the  time  restrictions  of  our  study  and  the  difficulties  of 
arranging  civilian  access  to  military  facilities,  we  were 
unable  to  do  a  more  complete  analysis  of  the  domain 
environment.  We  apologize  if  there  are  inaccuracies. 

An  obvious  source  for  reliability  data  for  a  given 
electronic  component  is  the  manufacturer.  However,  the 
only  reliability  data  readily  offered  by  the  manufacturers 
for  the  components  in  this  study  was  the  Mean  Time 
Before  Failure  (MTBF).  This  information  alone  sustains 
only  primitive  elapsed-time  replacement  rules,  the  least 
effective  type.  An  individual  component  costs  thousands 
of  dollars,  so  substantive  lab  testing  with  deliberately 
induced  failures  was  fiscally  impossible  under  our  own 
study’s  operating  conditions. 

We  had  hoped  to  locate  experts  in  systems 
maintenance  for  the  various  LRUs.  The  technicians  to 
whom  we  spoke  have  only  “black  box”  understanding  of 
the  individual  components  on  the  bus,  since  their  only 
decision  concerning  a  given  LRU  during  a  service 
session  is  whether  or  not  to  remove  it  from  the  vehicle. 
When  a  decision  is  unclear,  they  seek  guidance  from 
their  superior  officer — the  closest  approximation  to  a 
LRU  expert  with  whom  they  have  contact.  The  interior 
of  an  LRU  is  usually  considered  proprietary  information 
of  the  manufacturer  and  Army  personnel  are  not 
permitted  to  open  the  casing  or  to  view  a  wiring  diagram. 

Once  removed  from  a  vehicle,  an  LRU  is  sent  to  the 
depot  for  repair.  In  most  cases,  this  means  it  is  sent  to 
the  manufacturer.  So  again,  for  most  components,  the 
only  people  with  “expert”  knowledge  of  an  LRU  are 
directly  employed  by  the  manufacturer.  Such 
manufacturers  have  no  economic  incentive  to  reduce 
unnecessary  bench  services,  which  increase  their  own 
profits. 

No  indication  is  ever  sent  back  to  the  service  unit 
from  the  depot  concerning  the  actual  condition  of  an 
LRU  that  has  been  removed,  e.g.,  whether  it  was  indeed 
impaired  in  any  way.  The  depot  does  file  a  discrepancy 
report,  but  the  service  unit  has  no  access  to  this  report;  it 
is  sent  to  the  appropriate  subordinate  command  of  Army 
Materiel  Command.  Thus,  a  maintainer  never  leams 
whether  the  decision  to  remove  an  LRU  was  justified. 
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There  is  consequently  no  feedback  which  could  be  used 
in  machine  learning. 

Vehicles  using  this  particular  bus  architecture  are  in 
service  in  a  wide  variety  of  settings  world-wide.  Thus 
there  can  be  considerable  variation  in  the  exposure  to 
heat,  humidity,  dust,  and  so  forth.  Of  course,  vehicles 
can  themselves  move  from  one  location  to  anther. 
Maintainers  confirmed  that  climate  (especially  humidity) 
plays  a  definite  role  in  certain  types  of  failure  of  the 
LRUs  on  the  bus,  so  such  data  would  need  to  be  reflected 
in  reliability  models. 

An  important  aspect  of  this  setting  that  by  definition, 
a  LRU  may  be  removed  from  one  vehicle  and  later 
installed  on  another  vehicle,  possibly  in  a  distinct 
environment.  Replacement  rules  relying  on  elapsed  time 
(including  trend-based  rules)  require  that  it  be  possible 
for  the  maintainers  of  a  latter  vehicle  to  obtain  the 
service  history  of  each  transferred  component.  (The 
simplest  of  all  replacement  rules  require  knowing  the  age 
of  the  component.) 

Under  the  current  conditions,  tracking  of  individual 
LRUs  is  imperfect.  In  interviews  with  technicians,  we 
were  told  that  most  LRUs  are  tracked  by  serial  number. 
There  is  no  global  electronic  tracking  agency  for 
individual  LRUs.  Maintainers  also  admitted  that  not  all 
LRUs  are  identified  and  tracked  via  serial  number.  The 
radio  frequency  identification  tag  (RFID)  technology 
could  be  an  eventual  answer  to  accurate  tracking,  but 
such  a  system  is  not  yet  in  place  for  LRUs. 

Maintainer  said  that  they  have  access  to  the  entire 
service  record  for  each  LRU,  including  the  date  of 
manufacture,  number  of  hours  of  service  the  unit  had 
already  clocked  at  time  of  its  most  recent  installation, 
and  installation  date  on  the  current  vehicle.  Service 
records,  both  in  paper  form  and  electronically,  are  filed 
for  every  service  session  for  a  vehicle.  The  paper 
records  are  described  as  very  accurate. 

Existence  of  electronic  records  would  appear  to 
imply  the  existence  of  a  database  of  maintenance  data 
that  may  be  mined  for  performance  parameters.  When 
we  attempted  to  pursue  this  avenue,  we  were  advised  not 
to  proceed.  Although  the  electronic  report  for  an  LRU 
failure  includes  a  failure  code,  the  code  is  not  very 
specific.  Moreover,  apparently  the  data  entry  interface 
for  this  electronic  report  system  is  (or  has  previously 
been)  by  line  entry — it  is  impossible  to  “back  up”  and 
correct  a  line  previously  entered.  Since  most  of  the  users 
are  inexperienced  at  data  entry  and  consider  their 
primary  responsibility  to  be  repair  of  the  vehicle,  not 
filing  the  electronic  report,  many  entries  in  the  database 
are  suspect. 


Attempting  to  analyze  data  in  paper  maintenance 
reports  would  require  initial  funds,  personnel,  and  hours 
for  data  entry  before  any  data  analysis  could  begin. 

Maintainers  confirmed  that  an  important  source  of 
information  about  impaired  performance  comes  as  verbal 
reports  from  the  vehicle  user.  This  is  particularly  critical 
in  cases  of  intermittent  discrepancies — problems 
observed  only  when  the  vehicle  is  in  use,  and  not 
measurable  under  maintenance  conditions  (during  which 
the  vehicle  is  stationary). 

It  should  be  noted  that  under  current  regulations,  no 
data  recording  device  may  be  attached  to  the  vehicle  bus 
during  missions.  So  unless  these  restrictions  should  be 
modified,  any  effective  software  interface  for  prognostics 
(or  even  diagnostics)  must  support  maintainer  entry  of 
some  data.  Information  about  the  location/climate  could 
be  entered  by  the  user  as  well.  (The  vehicles  in  the  study 
had  a  GPS  unit,  but  it  was  not  resident  on  the  same  bus.) 

2.2.  The  Advanced  Multiplex  Test  System  (AMTS) 

We  now  considered  the  suitability  of  utilizing  the 
Advanced  Multiplex  Test  System  (AMTS)  itself  as  a 
data  gathering  device  (whether  for  reliability  model 
development  or  for  implementing  replacement  rules). 

Since  maintainers  are  already  required  to  submit 
both  paper  and  electronic  reports  for  all  maintenance 
performed,  we  knew  that  they  would  react  poorly  to 
AMTS  if  it  increased  their  work  burden  instead  of 
lightening  it.  It  seemed  ideal  if  AMTS  could  make 
automatic  session  records  with  very  little  effort  on  the 
part  of  the  maintainer.  For  this  to  be  possible,  the  AMTS 
should  be  able  to  capture  identification  information  for 
the  vehicles  and  LRUs.  Since  currently  LRUs  (and 
vehicles)  do  not  have  identification  markings  that  can  be 
captured  electronically,  identification  codes  would  have 
to  be  entered  manually.  However,  once  entered,  a  record 
of  these  codes  (for  each  individual  vehicle)  could  be 
retained  for  use  in  all  future  sessions. 

To  give  a  rough  summary  of  the  AMTS  bus-based 
diagnostic  design:  AMTS  works  by  capturing  very  brief 
time  samples  of  bus  messages,  while  the  vehicle  is  at 
rest.  Some  of  its  tests  analyze  the  data  passed  within  the 
content  of  messages,  and  others  the  actual  sequences  of 
the  messages  themselves.  (For  example,  one  message 
may  solicit  a  response  from  some  particular  LRU;  if  the 
correct  response  is  not  sent,  this  indicates  a  possible 
problem.) 

In  addition,  the  AMTS  makes  use  of  readings  from 
sensor-based  diagnostic  equipment.  Currently  such 
reading  must  be  entered  manually;  however,  the  AMTS 
architecture  is  designed  for  extensibility  in  the 
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anticipation  that  it  be  will  eventually  need  to  be  capable 
of  accepting  sensor  readings  directly  through  I/O. 

Finally,  the  AMTS  also  prompts  for  maintainer  input 
of  observations  that  may  not  be  subject  to  direct  reading, 
such  as  visual  appearance  of  LRUs,  and  problems 
reported  by  vehicle  users. 

AMTS  reports  its  summary  as  a  complete  picture  of 
the  current  bus  system  state.  In  cases  where  there 
appears  to  be  a  problem,  e.g.  some  LRU  is  not 
responding  correctly,  the  maintainer  can  use  the  AMTS 
to  investigate  more  thoroughly.  The  maintainer  can 
make  physical  adjustments,  followed  by  more  bus 
message  sampling,  in  order  to  isolate  and  eliminate 
failures.  (For  example,  there  may  be  a  problem  with 
cable  connections  rather  than  the  LRU  itself.)  AMTS 
users  report  that  they  appreciate  the  way  that  this  tool 
presents  a  complete  system  view.  They  appreciate  the 
way  it  supports  and  enhances  their  own  abilities  for 
critical  analysis  of  a  problem,  instead  of  being  required 
to  follow  step-by-step  text  instructions  founded  on  the 
presupposition  of  the  single  most  likely  single-point-of- 
failure — a  supposition  which  may  be  inconsistent  with 
the  actual  system  state. 

The  AMTS  includes  a  substantial  database  to  enable 
it  to  analyze  bus  messages,  and  it  can  determine  the 
organization  of  LRU  types  resident  on  a  given  vehicle 
bus.  However,  it  currently  lacks  any  ability  to  associate 
an  identifier  to  a  particular  vehicle  or  to  an  individual 
LRU.  Nor  has  it  any  ability  to  retain  any  data  read  from 
the  bus  (other  than  the  most  recent  sample  of  bus 
messages),  or  data  entered  by  the  user.  Thus,  currently  it 
has  no  capability  to  collect  and  store  historical  data  as 
used  in  prognostics.  It  also  currently  has  no  innate 
ability  allowing  it  to  interact  with  other  files,  programs, 
or  processes,  such  as  an  internet. 

CECOM  has  not  yet  planned  or  budgeted  for  any 
mechanism  for  data  collection  from  individual  units,  or 
for  establishing  a  central  database. 

2.3.  Summary  of  current  domain  conditions 

•  LRU  manufacturers  probably  possess  reliability  data 
in  excess  of  what  they  have  made  available  to  the 
Army. 

•  LRU  manufacturers  also  employ  the  most 
knowledgeable  experts  in  LRU  service  and  repair, 
and  indeed,  most  manufacturers  enforce  strict 
containment  of  that  knowledge. 

•  There  is  at  least  one  Army  electronic  database  of 
LRU  removal  information,  but  the  data  is  somewhat 
vague,  there  may  significant  corrupted  entries,  and 


entries  are  unassociated  with  any  feedback  about 
whether  removal  was  justified. 

•  Independent  lab  testing  would  be  expensive  (due  to 
high  cost  of  LRUs)  as  well  as  time-consuming. 

•  The  Army  personnel  making  preventative  LRU 
removals  never  receive  any  feedback  on  the 
correctness  or  timeliness  of  their  choices. 

•  Most  LRU  depot  maintenance  is  performed  by 
manufacturers,  who  have  no  financial  incentive  to 
provide  feedback  on  unnecessary  LRU  removal. 

•  Currently,  there  is  neither  global  nor  electronic 
tracking  of  individual  LRUs.  Tracking,  when  it 
occurs,  is  done  via  paper  and  (usually)  serial 
number. 

•  Reliability  models  for  vehicle  LRUs  would  almost 
certainly  need  to  reflect  the  location  of  vehicle  use 
or  its  climate  conditions.  This  information  can 
change. 

•  Currently,  AMTS  cannot  retain  data  or  share  it  with 
other  processes.  It  therefore  lacks  support 
capabilities  for  enforcing  time-dependent 
replacement  rules,  or  for  gathering  data  for  failure 
analysis  or  for  machine  learning. 

•  Certain  indicators  of  impaired  performance  only 
occur  when  the  vehicle  is  in  use.  Currently,  such 
indicators  are  only  observed  and  reported  by 
humans. 


3.  AN  ABSENCE  OF  EXPERTS 

One  unfortunate  aspect  of  the  current  field 
maintenance  situation  is  that  the  maintainers  do  not  have 
knowledge  of  or  access  to  more  experienced  experts 
(except  other  workers  at  their  own  sites).  It  seems  quite 
likely  that  under  current  conditions,  there  are  probably 
technicians  with  more  maintenance  experience  overall, 
but  there  are  no  real  known  Army  “experts”  for  any 
specified  LRU.  This  also  meant  that  we  did  not  have  an 
obvious  way  to  solicit  expert  advice,  such  as  could  guide 
the  choice  of  metrics  and  parameters  for  LRU 
replacement  guidelines. 

As  a  very  simple  first  approximation  to  an  expert 
system  for  prognostics,  we  suggest  a  secure  internet- 
based  service  where  maintainers  could  interact  with  one 
another  online  and  seek  removal  recommendations  for 
the  various  LRUs.  Such  a  service  would  be  more 
valuable  if  it  incorporated  a  mechanism  for  the  user  to 
rate  the  usefulness  of  a  given  piece  of  advice,  and  stored 
these  user  responses  (preferably  displaying  their 
statistical  distribution).  We  observe  that  as  optimal 
guidelines  may  reflect  local  conditions,  it  may  be  most 
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effective  if  posts  are  associated  with  some  location 
information.  (The  quality  of  advice  would  probably  be 
much  better  if  depot-level  maintainers  were  involved.) 
Not  only  would  maintainers’  resources  be  widened,  the 
advice  and  responses  culled  from  such  a  site  could  form 
the  nucleus  data  of  an  expert  system. 

As  far  as  we  can  discern,  there  are  currently  no 
“experts”  for  a  given  LRU,  other  than  depot  technicians. 
However,  it  may  be  possible  to  “create”  Army  experts. 

Since  there  are  over  a  dozen  LRUs  resident  on 
vehicle  bus  (and  potentially  as  many  as  31),  it  is  unlikely 
that  a  field  maintainer  will  develop  an  interest  in  the 
reliability  behavior  of  a  given  type  of  LRU 
spontaneously.  We  suggest  that  a  set  of  maintainers  each 
be  assigned  a  small  number  of  specific  LRUs,  for  which 
they  should  be  designated  as  a  “go  to”  person  at  their 
own  site.  The  maintainers  should  be  encouraged  to  make 
more  detailed  examinations  and  records  of  those 
specified  LRUs  during  maintenance  sessions,  and 
attempt  to  deduce  patterns.  These  maintainers  should 
also  be  encouraged  to  participate  in  the  online 
community  proposed  above.  By  making  the 
responsibility  for  a  given  LRU  focused,  rather  than 
distributed  over  a  large  number  of  LRU  types,  we 
believe  that  expertise  specific  to  individual  LRUs  could 
be  developed. 


4.  PROGNOSTICS  DEVELOPMENT 
RECCOMENDATIONS 

In  attempting  to  design  an  approach  to  prognostics 
for  the  AMTS  projects,  several  categories  of  issues  must 
be  considered. 

4.1.  Physical  architecture 

Physical  architecture  concerns  the  physical  factors 
of  a  domain  setting.  The  physical  architecture  for  the 
AMTS  project  includes  which  vehicle  models  (and 
variants)  are  to  be  maintained  by  AMTS  units;  which 
LRUs  are  used  on  a  specific  vehicle,  and  their  physical 
layout  on  its  bus;  the  distribution  world-wide  of  the 
vehicles  being  serviced;  the  existence  and  locations  of 
LRUs  which  have  previously  been  in  service  and  are 
expected  to  be  returned  to  service  in  the  future  (pending 
repairs);  and  the  physical  movements  of  vehicles  and 
LRUs  between  locations. 

Without  an  ability  to  associate  an  entire  service 
history  to  an  individual  LRU,  any  judgment  as  to 
whether  it  should  be  replaced  can  only  be  based  on 
current  observable  features,  i.e.,  its  current  measurable 
state  (no  time -based  features  or  trends).  Currently, 


service  histories  are  not  available  to  the  maintainer  in 
electronic  form. 

Some  recommendations  based  on  physical 
architecture  aspects: 

•  Design,  budget,  and  develop  a  central  database  for 
tracking  individual  LRUs  globally,  with  an 
expandable  capacity  for  retaining  histories,  using  a 
standard  format  such  as  XML  and  registered  DoD 
namespaces.  This  database  should  be  accessible  by 
both  field  and  depot  level  maintainers. 

•  Standardize  the  tracking  identification  of  all  LRUs, 
at  least  those  having  replacement  values  exceeding 
some  set  threshold. 

•  Radio  frequency  identification  tag  (RFID) 
technology  may  offer  a  practical  tracking  solution. 
This  possibility  should  be  investigated. 

4.2.  Information  architecture 

Information  architecture  consists  of  how  data  is 
measured,  where  the  data  is  stored,  and  how  various 
types  of  data  can  enter  the  system.  Currently  for  AMTS, 
data  enters  through  the  bus  and  user  entry  only,  with 
planned  expansion  to  incorporate  direct  input  from  other 
diagnostic  equipment.  However,  no  data  from  a  service 
session  or  specific  to  a  vehicle  is  retained. 

Some  recommendations  based  on  information 
architecture  aspects: 

•  Contact  the  LRU  manufacturers  for  any  reliability 
information  that  they  may  be  willing  to  share 
beyond  what  they  currently  provide. 

•  Initiate  a  maintainer’ s  web  forum,  as  discussed  in 
the  previous  section. 

•  Likewise,  recruit  or  designate  Army  maintainers  to 
monitor  and  study  specific  LRUs  in  the  course  of 
their  duties. 

•  Provide  any  known  reliability  information  (and 
expert  advice,  where  and  as  it  becomes  available) 
graphically  to  the  maintainer,  preferably  via  a 
(secure)  web-based  service. 

•  Expand  the  user  interface  capability  of  the  AMTS 
unit  to  support  entry  of  ID  data  for  a  given  vehicle 
and  its  (key)  LRUs.  A  copy  of  this  data  (say  on  a 
memory  peripheral)  should  be  stored  with  the 
vehicle  (until  electronic  global  tracking  is  fully 
operational),  making  such  data  entry  a  one-time 
necessity.  Use  a  standardized  format  such  as  XML 
and  appropriate  registered  DoD  namespaces. 

•  Add  to  the  AMTS  an  ability  to  load  and  update  data 
from  a  removable  memory  peripheral,  and 
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eventually  from  a  remote  source  via  network  or 
secure  internet  (such  as  NIPRNET). 

•  Add  to  the  AMTS  an  ability  to  save  key 
characteristics  of  session  data,  starting  with  basics 
such  as  date  of  service,  location,  and  any  LRU 
replacements.  Use  a  standardized  format  such  as 
XML  and  appropriate  DoD  namespaces  (developing 
and  registering  new  ones  if  necessary).  Assume  that 
data  fields  may  change  over  time. 

•  To  eliminate  the  necessity  of  duplicate  data  entry  by 
maintainers,  provide  a  mechanism  for  conversion  of 
the  session  summary  data  as  described  above  into 
any  required  report  formats  (electronic  or  human- 
readable). 

•  Begin  database  design  for  maintenance  records,  and 
determine  data  collection  mechanism.  Secure 
network  access  with  asynchronous  update  seems 
most  practical  and  effective. 

•  The  database  should  also  be  designed  to  accept 
depot  maintenance  feedback  for  a  given  LRU.  This 
data  would  allow  machine  learning  to  be 
incorporated  into  prognostication  software, 
permitting  gradual  automated  improvement  of 
replacement  recommendations. 

4.3.  Organizational  architecture 

The  organizational  architecture  describes  the 
intended  use  and  deployment  of  a  system.  It  includes 
what  types  of  users  the  system  will  have,  and  how  these 
various  types  of  users  will  interact  with  the  system.  In  a 
military  context  it  also  includes  the  Army  organizational 
structure  and  its  policies.  For  AMTS,  we  consider  both 
field  and  depot  maintainers,  and  also  Army  practices 
affecting  them. 

To  some  small  extent,  one  of  the  proposals  above 
does  cross  into  organizational  issues.  By  establishing  a 
net-centric  community  in  which  maintainers  at  different 
locations  and  levels  of  expertise  can  interact,  an 
alternative  information  mechanism  becomes  available, 
one  outside  of  Army  organizational  lines. 

As  we  have  outlined,  most  LRU  manufacturers 
provide  little  reliability  information,  and  also  are  the  sole 
source  of  depot  maintenance  for  their  products.  They  do 
not  provide  feedback  to  the  field  maintainer  on 
inappropriate  LRU  removals,  nor  is  it  in  their  fiscal 
interest  to  do  so. 

Although  the  Army  Aviation  Condition  Based 
Maintenance  Plus  (CBM+)  Plan  (Enderle,  2004) 
describes  the  necessity  of  a  close  working  relationship 
between  manufacturer  and  Army  engineers  in  developing 
effective  algorithms  and  metrics  for  maintenance,  it  does 


not  explain  how  this  cooperative  state  is  to  be  brought 
about.  The  plan  does  not  address  the  lack  of  feedback 
for  preventative  LRU  removals. 

Realistically,  there  is  little  CECOM  can  do  directly 
that  can  change  organizational  issues,  which  hinge  on 
Army  policies.  Thus,  our  only  recommendations  based 
on  organizational  architecture  issues  are  really  addressed 
to  Army  practices: 

•  Advocate  change  in  Army  policies  regarding 
purchase  and  service  contracts.  Reasonably 
substantial  and  informative  reliability  information 
should  become  a  pre-condition  to  purchase  of  new 
units.  Service  contracts  with  outside  providers 
should  include  a  proviso  that  field  maintainers  will 
receive  some  meaningful  and  reasonably  timely 
feedback  about  the  condition  of  LRUs  they 
removed.  Preferably,  such  feedback  will  eventually 
occur  concurrent  or  en  route  to  an  update  of  the 
proposed  maintenance  database,  so  that  this 
feedback  information  becomes  part  of  the  permanent 
record  (and  can  be  incorporated  into  machine 
learning). 

•  For  manufacturers  wishing  to  retain  tight  proprietary 
control  of  service  and  of  performance  data,  an 
option  is  for  the  Army  to  require  the  manufacturers 
themselves  to  provide  clear,  enforceable  reliability 
replacement  rules.  Service  terms  should  be  designed 
to  reduce  the  financial  incentive  of  unnecessary 
removals.  For  example,  for  LRUs  removed  under 
these  preventative  rules,  service  fees  might  be  based 
on  net  vehicle  mission  hours,  rather  than  per  unit 
processed. 


CONCLUSIONS 


An  effective  system  for  preventive  and  predictive 
maintenance  can  result  in  savings  many  times  in  excess 
of  its  initial  and  support  costs.  Such  an  approach  is 
particularly  vital  in  times  of  flat  military  budgets  and  the 
necessity  of  maintaining  legacy  and  often  technically 
obsolete  equipment.  Operational  lifetimes  of  U.S. 
military  vehicles  are  currently  being  extended 
significantly  beyond  the  original  design  limits.  In  the 
1990s  the  Air  Force  observed  the  mission  capability  of 
its  fleet  declined  10%,  largely  due  to  the  age  of  the 
avionics;  by  2001,  it  was  spending  over  $250  million  a 
year  coping  with  obsolescence  issues  (GETS,  2001).  As 
maintenance  costs  increase,  they  consume  a  greater  share 
of  the  military  budget.  More  and  more,  the  Army  is 
realizing  that  equipment  acquisition  must  be  assessed  in 
terms  of  total  cost  of  ownership. 
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In  this  study,  we  focus  on  field  maintainers  using  the 
Advanced  Multiplex  Test  System  (AMTS)  diagnostic 
tool.  Existing  domain  circumstances  make  development 
and  implementation  of  effective  predictive  maintenance 
for  vehicle  Line  Replicable  Units  (LRUs)  very  difficult. 
However,  we  have  outlined  a  few  initial  steps  that  could 
provide  some  immediate  assistance  to  the  field 
maintainer  in  making  replacement  decisions,  while 
enabling  collection  of  data  that  could  support  an  eventual 
global  net-centric,  self-evolving  capability  for 
prognostics. 

We  propose  a  data-collection  mechanism  which 
would  actually  lighten  maintainers’  recordkeeping.  We 
also  describe  a  simple  means  for  culling  human  advice 
and  for  creating  “experts,”  as  well  as  a  means  of  making 
their  advice  readily  available  to  other  maintainers.  These 
precursor  steps  can  gather  seed  data  for  mining  (to 
determine  patterns  of  failure),  and  gradually  enabling 
more  rigorous  future  collection  of  data  suitable  for  model 
validation  (to  verify  or  adjust  inferred  patterns),  and 
machine  learning  (to  allow  continuous  refinement  of 
failure  models  and  deeper  incorporation  of  operational 
environment).  As  unique  identification,  embedded 
diagnostics  and  health  utilization  monitoring  systems 
become  available,  AMTS  will  be  ready  for  true 
condition-based  maintenance. 
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